With the advent of 3G mobile telephony, new packet-based communication technologies have been developed for communicating multimedia content. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video clips, etc., in addition to traditional circuit-switched voice calls. Further, new sophisticated mobile terminals are also emerging on the market, equipped with functions and features to handle the new services, including high resolution colour displays and multiple codecs (coders/decoders) for different multimedia formats.
Recently, a service network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to provide multimedia services in the packet domain for primarily mobile clients. Generally, IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used and basically not restricted to any limited set of specific services.
Briefly described, an IMS network can be connected to different access networks, such as mobile (or cellular) networks or broadband access networks, to enable multimedia sessions for terminals in communication with those access networks. Among other things, an IMS network contains session managing nodes, subscriber databases and various application servers. The session managing nodes are used for controlling multimedia sessions, including the nodes S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). Invoked multimedia services are enabled and executed by the application servers. Further, a main database element HSS (Home Subscriber Server) stores subscriber and authentication data as well as service information, among other things, available to the application servers and session managing nodes.
A specification for session set-up has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261 et al), which is an application-layer signalling protocol for controlling sessions over a packet-switched logic. SIP is generally used by session managing nodes in IMS networks in support of multimedia services. The concept of IMS service networks is well-known in the field of telecommunication, and the various functions of the IMS network elements are not necessary to describe here further to understand the present invention.
One example of services that can be employed by means of an IMS network is the so-called “Presence” services. Presence services basically involve the publishing of “presence data” of a user to make it available for other users and applications, which further can be used to control other services in turn. Presence data basically defines the state or situation of a user and his/her equipment in some predefined respect. Thus, the term “presence” is here given a very broad meaning, and the presence data may include, by way of example, the following:                A user identity chosen by the user for presence communication by which he/she is known to other users, e.g. as an alias.        A user status, e.g. available, busy, in a meeting, on holiday, etc.        A terminal status, e.g. switched on/off, engaged, out of coverage, etc.        The geographic location of the user/terminal, as well as other aspects on the physical condition of the user/terminal. In future extensions of the support, this may include: acceleration, orientation, light condition, temperature, etc.        Terminal capabilities and selections, including functions for SMS, MMS, chatting, games, video, etc.        Other personal user information, e.g. interests, occupations, personal characteristics, moods, etc.        
This information, or any selected parts thereof, is stored in an application server in the IMS network, based on so-called “publications of events” received from the network or a user, whenever the user changes any of his/her presence data. A user may also subscribe for selected presence data of one or more other users, e.g. according to a list of users. Such presence subscriptions are typically also handled by an application server in the IMS network. The subscribing user can then receive notifications regarding current presence data, either automatically or upon request. In SIP, a message called “SIP PUBLISH” can be used to provide dynamic data to an application server in the IMS network. Further, another SIP message called “SIP SUBSCRIBE” can be used by users to subscribe for dynamic data of other users, as handled by the application server.
The presence services are thus typically based on different communication groups of users that can be established around various subjects, such as a football team, a chat group, a working project, etc, and contact lists are maintained for such groups. When belonging to such a communication group, the members are naturally willing to communicate with other group members using certain specified functions and types of media. Thus, the set of available functions of a particular user are “exposed” to the group by means of the presence data and the above-mentioned publish/subscribe mechanisms.
However, the mere fact that available functions and media types are exposed in this way for different users makes the users susceptible to illicit attacks or “spamming” over those functions and media types, e.g. after interception of messages communicated for the presence services. Further, users may have good reason to be cautious when being contacted by unknown parties since replying to a communication request or invitation will typically expose and even validate the current address of the called user to a potentially malicious caller. Depending on the addressing standard used, the exposed address may include an IP address, an e-mail address such as SIP-URI, an alias associated with an SIP-URI, etc.
The following discussion may be valid for any type of communication request or invitation from a calling party, including traditional voice calls and also for any type of multimedia communication. For example, a calling party may send a multimedia communication request or invitation with the intention of sending or fetching content, e.g. a “file”, in any format for texts, images, video clips, audio, animations, etc.
Any user of a communication terminal has typically created one or more contact lists in the terminal containing at least the name and contact number/address of known individuals such as friends, relatives and colleagues, hereafter referred to as “known parties”. The known parties may naturally also include members of any communication groups the user currently belongs to, e.g. using presence services according to the above. Contact lists for such communication groups are then maintained in corresponding application servers in a service network. Further, search engines are also available over the Internet holding personal relationships, sometimes referred to as “friend-of-a-friend” data. In the case of presence services, each entry in a contact list is associated with different media that can be used for communication with that contact or party.
If a user receives a call or session invitation from any known party present in such a list or group, the receiving terminal will typically notify the user automatically on the identity of the calling party on a terminal display or by means of a specific ring signal or the like. Thereby, the called user can decide how to respond depending on the identity of the calling party. In some cases, the terminal may itself decide how to respond automatically, e.g. based on the caller identity, any relevant contact lists defined for the called user including “black lists” or “white lists”, respectively, or similar. This automatic response function is typically implemented as a user agent, or so-called “presence agent”, either in the terminal or in an application server.
On the other hand, if a call or session invitation is received from an unknown party not present in any contact list or group defined for the receiving user, he/she (or a user agent) will be unaware of the caller's identity and/or not recognise the calling number if displayed, before responding. In that case, the called user or user agent has basically three options: 1) respond with a message implying acceptance to communicate, 2) respond with a message implying rejection to communicate (which may be a so-called “polite block” message in the style of “out-of-office” or the like), and 3) not respond at all. It should be noted that options 1) and 2) may effectively open the user for potential illicit attacks, whereas option 3) will be safe in that respect but the called user may then on the other hand neglect a potentially interesting and desirable communication with the calling party.
FIG. 1 illustrates schematically a typical communication scenario where multiple contact lists have been defined for a user A 100, of which a first list 102 and a second list 104 are shown, for various purposes such as contact lists in the manner of a “phone book” or the like, or group lists for presence services, etc. The contact lists 102, 104 . . . may be stored in the user's communication terminal and/or in an application server e.g. handling corresponding presence services or the equivalent. The first shown list 102 includes users B,C, D . . . making up a first user group G:102, and the second list 104 includes users L,M,N . . . making up a second user group G:104, as schematically illustrated. In this context, the term “user group” generally represents a set of users in any contact list, presence group, etc., pre-defined for the called user. Of course, further user groups, contact lists or the like, not shown, may have been defined for user A.
If a communication request R:102 or R:104 is received from any known user in group G:102 or G:104, respectively, the calling party identity and/or number/address will be known to user A and/or the receiving terminal accordingly, forming a basis for how to respond. However, if a communication request R:X is received from an unknown user X 106 not present in any contact list or group defined for the receiving user, the number/address of the calling party is unrecognised and user A, or the receiving terminal, cannot take the caller's identity into account when deciding how to respond.
Generally, it is a problem that communication terminal users and/or their user agents have insufficient or no basis for deciding how to respond to communication requests and invitations from unknown calling parties. It is also a problem that a called user has no possibility to know whether an unknown calling party can be regarded as “reliable” or not in some respect, or whether he/she is generally suitable to communicate with, e.g. as discussed above.
US 2006/0046720 A1 discloses a solution for giving to a mobile terminal user, identity information about a calling party that tries to establish communication with the mobile terminal. This solution may thus provide improved identification of the calling party, but would still not be helpful for assessing the caller's reliability if the given identification is unknown to the called party.